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ABSTRACT 


Evolving requirements including the development of the 
Joint Operation Planning and Execution System (JOPES) are 
forcing the WWMCCS ADP community toward the development of a 
distributed data base approach to information management. In 
this thesis the Electronic Data Interchange (EDI) concept is 
examined as a proposed system for realizing a distributed 
data approach. Using the EDI concept, any command which could 
translate to and from the EDI standard data set could exchange 
data with any other participating command. Implementation of 
this sort of system would facilitate interfaces among commands 
while not limiting participating commands to specific hardware, 
software, or data base management systems. The thesis proposes 
the EDI concept as a step toward realization of better data 


distribution and management in WWMCCS ADP. 
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I. INIRODUCTION 

ЕШ спе -костантаое ,Мізтагу Command and Control System 
(WNMCCS) current AD? capabilities do not provide sufficient 
support for the exchange of data among commands in a timely 
and effective manner. ІШ order to exchange data today, 
generally, commands must have the Same hardware and soft- 
маге. In some other cases specific soztware must also be 
developed to exchange and translate data between applica- 
Bons which are  interfaced. These conditions cause 
inefficient use of resources and severely limit caparilities 
to respond to command and control requirements. 

Evolving requirements including the development oí the 
Joint Cperation Planning and Execution System (JOPES) аге 
forcing the WWMCCS ADF community toward the development or a 
distributed data base approach to information management. 
In tnis thesis the Electronic Data Interchange (EDI) ccncept 
is examined as a procsed system for realizing a distrirtuted 


data approach. 


ШЕШЕЙ: 5. Electrcnic Data Interchange (EDI) Standards 
are designed tc facilitate the electrohic interchange of 
data in ^a standard manner fetween indeperdently crgan- 
ized, cwned, and/or operated computer and communication 
systems. .. 4 The EDI standards jrew from needs in 
transportation andfaydent applications and have teen 
extended for use in other business and technical appli- 
Sations." (Ref. 1: p. 6] 


Implementation of this sort of system would facilitate 
interfaces among commands while not limiting participating 
commands to specific hardware, software, or data base 


management systens. 





Chapter II of the thesis provides background by defining 
WWMCCS, and WWMCCS ADF, and explains tne current aprroach to 
WWMCCS ALF management. Chapter III discusses the ¿rotlens 
of data management in conventional planning and execution. 
In this Chapter specific problems are identified alcng with 
documented requiements which cannot be satisfied using the 
current procedures. Chapter IV, Recommendations, includes 
some background on current capabilities in ADP which could 
ke exploited for better command and control. їп acdition 
the Electronic Data Interchange (EDI) concept is examined as 
a proposed system fcr meeting evolving WHMCCS AD? data 
Management requirements. EDI is evaluated in its potential 
to alleviate the specific problems which are identified in 
Maapter ІІІ. Chapter V provides a summary of how the EDI 
concept could help improve data interchange among commands 
and includes an illustration of an EDI application. 

Ihe thesis  rropcses the EDI concept as a step toward 
realization of better data distribution and management in 
ANMECS ALP. 





А. WWMCCS ADP OBJECTIVES 


"The WWMCCS is the Worldwide Military Command and 
Control System that provides the means for operational 
direction and technical administrative support іпусіуей in 
the function of command and control of United States mili- 
БЕУ Тогсевсв," І|Кег. 2|. The elements of WWMCCS are; 

~ warning systems 

- ccmmunications 

- ссшпапй iacilities 

- executive aids 

- data collection and processing 

Тһе WWMCCS ADP System includes the ADP hardware, system 
software, applicaticn software, data bases, files, proce- 
dures, data management system(s), related personnel, data 
communications equipment, and circuits. The ADP suppcrt at 
the Service headquarters and Service component levels may be 


a nix cz both WWMCCS and unique systems. 


E c ПИМСС5 АрР system(s) must snper both the primary 
and secondary missions of the WW4ACCS3 as stated іп LoD 
Directive 5100.30 and JCS PUE 19. In doing so, the ADE 
System will Ene command and control requirements 
Of the National Military Command System (NMCS), unified 
and specified commands Conponent commands, Service 
headquárters, subordinate unified commands, J?TFs,  TOAs 
the Joint Deployment Agency  (JDA) and the Jcin 
Semacegic Target  Flanning Staff (25125), and related 
functions ofi other defense agencies. ne system must 
Support the decisionnakers and their staffs by 
providing; 


timely and accurate information on the status and 
locaticn of forces and major resources 


ehe capability toc Bete Sapa ne implement both conven- 
i 


tional and nuclear operations plans and options 





апей саа асру се сорпиласе апа transmit direction 
to and receive and assess reports írom the aprrc- 
priate commands and organizations 


the Y womeapidly апа el exchange 
EDfcrmation, oth laterally and vertically, across 
service and command boundaries... 


In general, meeting these objectives will result ina 
muabslIrty to capture, transmit, and process information 
in a tinelv and accurate fasnion and to display useful 
and easily understccd formats." (Ref. 3: p. 535 


Ihe NWHYCCS ADB Concept or Operations and General 





Requirements for Post-1985 was approved by the JCS ana the 
Services in 1981. The documentation identified four func- 
tional families of processing requirements within WWMCCS 
ADP. Mcst WWMCCS applications software and data bases can 
te grouped into one cf these functioral families: 

- Pesource and Unit Monitoring (RUM) 

- Ccnventional Planning and Execution (СРЕ) 

- Nuclear Planning and Execution (NPE) 

- Tactical WarningyAttack Assessment and Space Defense 

(TW/AA and SD) 

Conventional Plarning and Execution will be used to 
illustrate some of tke problems which can result when there 
1s insufficient provision for interfaces among data bases. 
Conventional Planning and Execution (CPE) generally includes 
tne Cevelorment, maintenance, and execution ОЕ operation 
plans for the deployient and employment of United States 
military forces. CPE includes: 

- Generating and refining operatonal requirements 

- Merging requirements Егсш difrerent pians 
EEDeterzmining oplan feasibility 

- Matching requirements with actual resources 

Е Developing and disseminating scheduies and orders 
- Identifying shortfalls and limitations 


- Rapidly reflowing movement requirements 


10 





uu o»ordiugatilon  anmdomonitoring mobilization and 2есісу- 
nents 


- Aggregating and summarizing requirements 


Ine CPE function relies heavily on ADP support  esre- 
cially since the JCS has directed that the Joint Operational 
Elanning System (JOPS) be used in planning for oferations, 
force deployment, and support of 0.5. JO cee st ary 
Operations. "The JCES consolidates policies ani procedures 
for the development, coordination, dissemination, review and 
approval cf joint plans for the conduct of military opera- 
вое," [Ref. 4: p. 3]. In addition, the members of the 
Joint Deployment Community (JDC), which includes the unified 
and specified commands, component commands, Services, TCAs 
and JCA, use the Joint Deployment System in support of oper- 
ation plan execution and monitoring. To communicate and 
coordinate among ccmzands in support of CPE the WWMCCS 
Intercomputer Network (FIN) is used. Many command and 
service unique software applications are used tc prepare 
data for input to JOES and JDS, but interfaces among these 
unique applications and JOPS and JDS are for the mest part 
manual as is the interface Геечееп JOPS and JDS. 


В. WHMCCS ADP MANAGEMENT 


The management rproach which tas prevailed in WWMCCS 
ADP has teen one of standardizing  sortware as well as hard- 
ware. Management procedures for the WXMCCS standard ADP 
system are promulgated in JCS PUB 19. The procedures 
support the acquisition, maintenance, and continued improve- 
ment of the WWMCCS standard ADP system and apply to its 


users. Cbjectives of these procedures include: 


dice tre duplication of effort in design, develop- 
nent, geguisıceıon, and maintenance of WWMCCS ADE 
hardware, applicaticn software, and system software, 


11 





maximize. the tenefits of compatibility, and 
standardization of WWMCCS ADP hardware, BB ication 
ao twarece, and system software," [ Ref. 5: р. 11-14] 


С. WWMCCS ADP STANDARD APPLICATIONS SOFTWARE 


и pcc цев Software or portions thereof,  devel- 
are: within a, command, agency or Service or for the 
emoaicman, Joint Chiefs of Starf, will often have 
рава хсасіаа су со dike Ccommand-levei WWNCCS activi- 
ties or the other соппапс levels with common 
requirements or Similar information needs... In 
соаг where a Service, agency, or command or 
he Chairman, Joint Chiefs of Staff, has an existing 
capability to perform a specific technical support 
taSk, that enger will be utilized, to the 
maximum extent feasible rather than initiatin a 
separate development effort." [Rei. 5, p. III-2 


What this means in the WWMCCS ADP conmunity is that an 
individual command, Service, or agency is assigned as the 
Designated Responsible Activity (DRA) for development and 
Standardization of a specific application which has been 
apprcved as a standard. Ihe OJCS C3 Systems Directorate 
maintains ccgnizance over all standard systems in an effort 
to avcid unnecessary duplication and attempt to meet a troad 


spectrum of user requirements. 


| By the late 1980s, this ."stardard" WWMCCS ADP with 
lts prccessors and associated software will be techno- 
logically obsolete, У асуу ап dirficult 
moesurrort logistically. (Modernization will require 
both new hardware and new applications software and 
Estem software)." [Ref. 6: р. Е5-1) 


Much of the standard applications sortware was written 
originally to operate in a batch processing environment 
which makes it. inefficient and often ineffective for crisis 
support which generally requires interactive capability. At 
present a data base must be resident on the same computer as 


the executing application. This means that every site using 





an application must have access to copies of the relevent 
software and data base on the system on whicn the processing 
will te done. Many commands have modified their ccpies of 
the standard applications to better suit their unique 
requirements so that it is actually no longer the standard 
applicaticn software. 
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III. PRCBLEMS 


ғ гр 


A. THE CPE ENVIRONMENT 
1. Elanning 


ihe JCS has directed that the Joint Operation 
Flanning System (JOPS) will Бе used in planning for opera- 
tions, force deployment, and sapport of US joint military 
operations. JOPS supports planning under time-sensitive or 
crisis conditions with procedures which form the Crisis 
Action System (CAS). Under non-crisis, peacetine situaticns 


JOPS is employed in the deliberate planning process. 
а. Deliberate Planning 


Deliberate pianning consists of five phases 
Rhich are outlined in Figure 3.1 [Ref. 4: p. 3] 

The majcr product created during the plan development phase 
cf JOPS is the time-phased force deploynent data (TPFDD). 
When planning is complete, the TPFDD contains all of the 
information needed tc describe a deployment. TPFDD refine- 
nent is conducted ina two-phase conference hosted ty the 
Joint Derloyment Agency (JDA). 

The WIN is utilized as a timely, secure means of 
distributing data to the deplcyment community to facilitate 
the refirement process. Prior to the Phase I refinement 
conference the WIN is used to distribute the unrefined 
IPFDD, which contains only notional data, to the deplcyment 
community in order tkat initial analysis can be conducted 
prior to the conference. During the Phase I conference as 
actual fcrces are designated to replace the notional forces 
in the TEFDD and transportation requirements are identified, 
the  IPFDD 1s updated to reflect these Changes and 
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Phase | Basis: National Security Objectives 
аиса Criteria: The Threat 
Planning Tasks and Forces 
Objective: ToSetthe Stage 
Basis: Mission Assignment (Forecast Situation) 
Phase Il Concept Criteria: Force and Resource Allocation 
Development All Significant Factors 
Objective: Derive the Concept of Operations 
Basis: The Commander's Concept 
EHE Criteria: Force and Resource Aliocation 


Service Planning Factors 
Strategic Movement Data 
Concept Adequacy 
Objective: A Transportation Feasible, Implementable Plan 


Plan 
Development 


Basis: The Plan 


Phase IV Criteria: Adequacy, Feasibility, and Suitability 
The Dynamics of Change 
Objective: An Approved Plan 
Basis: The Approved Plan 
ace supporting Criteria: Service Doctrine 


Plans Support Agreements 


Objective: A Family of Plans 


A A e o gp A ,...қуқ ee адга EEE u: те 


AA AP ———————————————— Vc,  ——À M D — eee ee ————————— — ——— 





mM | 

Lows ы ы атана ды ылы са а ес 
Figure 3.1 Deliberate Planning. 

distributed to the TOAs. Each of the TOAS uses command 


unique applications software to prepare movement schedules 
suppcrting the requirements in the TPFDD and to check the 
resulting schedules for feasibility of execution, identif- 
ying shcrtf£alls (requirements which cannot be met). 
Military Airlift Command (MAC) forwards the TPFDD Еу НІМ to 
Military Traffic Management Command (MTMC) after identifying 
eml ift in support cf the plan and checking the plan for 
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Eeasibility. КЕМЕШ рготі Оев гог ground transportation and 


Q 


ркапсрогтабіоп within the continental United States, «IM 
identifies and tests for feasibility the transportation 
suppcrt to be provided by MIMC. The WIN is used again to 
Bonward the TPFDD tc Military Sealift Command (MSC). Ihe 
sealift support for the plan is identified, as well as the 
resulting shortfalls, and the ITPFDD , with air, ground, and 
sea transportation identified, is forwarded by WIN to the 
Joint Deployment Agency. In addition, the modified TPFLID is 
distrikuted to the deployment community for review of short- 
falls pricr to the Phase II conference. During Phase II of 
the refinenent process as shortfails are studied the plan is 
modified tc resolve the shortíalis, resulting in the 
requirement for reflcwing the transportation support. 

When the TPFDD has been refined and the 
resulting CELAN reviewed and approved by the Joint Chiefs of 
Staff, it is then entered into the deployment data base at 
JDA and 1S accessible to the deployment community Еу means 
ШЕ тіс WIN. 


Е. Plan Maintenance 


An ongoirg teleconference is maintained for each approved 
OPLAN in order to provide a forum for discussing changes 


required to maintain and update tne plans. 


ату Ее first 15 days of airlift and the first 30 
Gays of sealift are reviewed by the appropriate members 
of the Jcint Deployment Community, who verify that the 
units and material designated in the plan are actually 
availalle, ard wculd most likely be the ones used, 
Should the plan be executed... upon completion ог the 
Mainterance cycle, спе revised: data replaces the 
outdated requirements in the Joint Deployment Systen 
ENDS), [Bef. 7: р. 13]. 


Ihis review is usually conducted quarterly. 
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с.  Time-sensitive Flanning 


The Crisis Action System (CAS) which is utilized 
for tine-sensitive planning has six phases as illustrated in 
ШО гє 3.2 [Ref. 4: р. 7]. 

In the situation development phase commanders 

can use the WIN to submit Operational Reports (OPREPS) to 

appropriate authorities. CPREP messages are used to ccmmu- 
nicate ccncerning incidents or conditions which could evolve 
mato a crisis. 

In the crisis assesment phase WIN is used to 
conduct a teleconference in which representatives from the 
NMCC, the Service headquarters, the Unified and Specified 
Commands, the JDA, and the TOAsS participate. 


n7 
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In the ccurse of action development phase the 
WIN is utilized as the transmission mode for the OC2zmzP-1 
messages used to exchange required inrormation. Using CPREP 
messages on the WIN, JCS promulgates a warning order, the 
supported commander then tasks the deployment community for 
required assistance іп developing or revising plans. The 
depolyment community in turn forwards responses and the JDA 
updates the JDS data base for the plan being developed or 
nodified. 

In the execution planning phase WIN is used for 
transmission of the alert order and operation order. The 
deployment community develors supporting operation orders as 
required and uses WIN to fcrward updated information to JDA 


mor inclusicn in the JDS data Газе. 


2, Execution 


атпшеп о 
order, the JDS must monitor status of ung forces, 
material, and non-unit related personnel...JDA must alsc 
be abl c rapidly respond to changes in the deployment 
as execution processes." [Ref. 7: р. 16] 


"The Jcint EE Ment Scr supports deployment execu- 
tion and sus ‚zorces...äfter the JCS execute 


The JDS capakilities supported by WIN, which are 
available tc the joint deployment community during deglcv- 


ment execution are: 


- A teleccnference is used to exchange textual informa- 
tion among the memkers of the deplovment community to 


assist in decision taking. 


. 


~- Access to the JDS data Ease is available by one of the 


following means: 


i» 





== Direct access to the JDS data base 15 
possitle using WIN to access the timesharing 
subsystem of tbe JDA host computer. By this 
means remote users can review or update the 
JDS data base. 


-- Transfer of porticns of the JDS data base 
to rerote sites is possible using WIN. Then 
users at remote sites can run command unique 
applications programs using their copies of 
the JDS data base. These copies of the data 
base will not reflect updates to the data base 


at JDA unless a later transfer is initiated. 


-- Direct access to the JDA data base 15 
possitle throught the JDS Remote Users Package 
(RUP) which permits the user to update a local 
Copy cf the JDS data kase while simultaneously 
updating the JIS data base resident on the JDA 
ccuputer. This permits commands to have 
access to the frost up-to-date version of the 
JDS data base cn a real time basis. 

The RUP is ccnsidered to be the prefered methcd for 
timely transfer of information between JDA and the rencte 
sites since it not cnly provides the remote user the cara- 
Lility fcr timely submission of updates and changes tut also 
permits the remote user to recieve chanjes sinultaneoulsly 
as the JDS data base is updated by other members of the 
deplcyment community. In addition the ВОР permits the 
remote user to run command unique applications programs 
using the local copy cf the data base. "As part of the RUP, 
the JDA has developed communication support software called 
tne JDS Interface Frocessor which uses existing WIN to 
support transaction updates between two WIN sites in near 
real time." (Ref. 7: p. 70]. 


20 





Тһе JDS also interfaces with MAC and MTMC using azN 

to transfer informaticn to and froa 

- the Integrated Military Airlirzt Planning Systen 

(IMAPS) at Military Airlift Coamand 

- the Mobility Analysis and Planning System (MAPS II) at 

Military Traffic Management Command. 
These autcmated interfaces facilitate the timely exchange of 
movement reguirements and scheduling information between JDA 
апа tke TOAS. 


Bee SEECIFIC PROBLEMS 


Several examples cf the kinds of problems which cccur in 
processing in a distributed environment сап ove fcund in 
examining the JDS as fart of the WWMCCS ADP support for СРЕ. 


а. Interface Between JOPS and JDS 


The JDS is the ADP tool used to manage inicrıa- 
tion in support of deployment and OPLAN execution. In order 
to properly support its mission the JDS must interface with 
JOPS which is used tc develop oplans. The current interface 
is, "time-consuming and relies heavily on manual reviews and 
Dear pulation of ‘data'," [Ref. 8: р. 8]. The JOPS handles 
notional data, dealing with types of units rather than 
specific named units. JDS, however, has in its data tases 
specific named units which will be used in specific plans. 
Border to obtain the proper information for the JDS data 
Lase, manual reviews cf the notional JOPS data are conducted 
and after specific actual units are named in suppcrt of 
requirements, the JDS data base is prepared. In addition, 
each cf the TOAs requires support from command unique soft- 
ware to ccnvert the notional movement tables from JCPS into 
schedules which use actuali named assets. These schedules 


are then used to provide input for the JDS data base. 
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The interfaces among these systems are primarily 
Manual at tne present time. In addition, although the VIN 
is used to transfer data between participating ccmmands, 
each ccuzand running JOPs uses its own copy oi the TPFDD 
during processing as well as its own copy of the JOES soft- 
ware. This results in considerable duplication of files and 
HEesujting requirement for extensive coordination tc ensure 
each site is using copies of the same TPFDD data rase in 


order to prevent decrepancies. 
CENO ELCAN TSU port 


"There are no adequate procedures to rapidly 
establish a deployment data base in a NOPLAN situation," 
[Ref. 8: р. 11]. Since in the current JDS the only way to 
review data is in ccnnection with one specific OPLAN ata 
tine, it is difficult to efficiently use data already in the 
data kase in support of a NOPIAN situation. There is not 
even automated assistance to determine which units are 
tasked tc support more than one OPLAN. This is a deficiercy 
in the current System Since there is a validated requirement 
that, "The JCS will review the supported commander's esti- 
nate and approve or ıcdiiy the recommended course of action 
after determining tke effect on other operation plans and 
ШӘБаі capabilities," [Ref. 9: р. 12]. There is currently 
no timely, efficiert way for commanders to share NCPIAN 
information when developing potential courses of action 
without actually sending copies of data bases or iengthy 


messages between comıands. 
с. Data Base Inconsistencies 


The primary method for transfer of data amcng 
commands using the JIS is the WIN. Recent tests ccnducted 
during a major exercise have shown іп а fairly small sample 


ӘР JDS data base records that there are numercus 
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inconsistencies among copies:oí the data base at  varicus 
sites (Jcint Deployment Agency, European Command, Military 


fee litt Ccmmand) ; 


"The technique we used to determine the synchronization 
of JDS data bases was to select a sample of carrier 
reccrds and determine if the inzormation was the same in 
eacb ort trie three data bases. . «This oplar has thou- 
sands of carriers, so we limited our sample tc thcse 
carriers we knew had been updated--those with Deviation 
and /or Diversion reports. we retrieved carrier nani- 
fest data on forty-five records stored at each of the 
three locations . . . In summary, ECT small sample 
oí carrier records having been nodiried Бу deviatıony 
diversion reports had a high percentage or differences 
between RUP ànd JDS data basés. (Ref. 19] 


The data shown furnishes examples of the discrepancies 
found: (Ref. 10] 


CARRIER 403895 SCH ARR 
EUCCM ZESNZBZEEBE-ATSBRUSSELS 
JDA 250000 0FEE AT BRUSSELS 


Discrepancy: a difference in scheduled arrival time 


CARRIER 404526 SCH DEP 

= ОСОМ ЕТСЕ COLORADO SPRINGS (TDAV) 

JDA FETERSON FIELD (ТОНЯ) 
Discrepancy: a difference in the name associated with a 


specific location ccde 


CARRIER 404021“ SCH ARR 
EJCCM 2591626 ZFEB 
JDA 2500000FEB 


Discrepancy: a difference in the scheduled arrival time 


CARRIER A04182 SCH ARR CARRIZR DEVIATION 
EUCCM 20 I65 1 ZFER ERST 
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JDA 260000 0FEE DECAYED 2 edCU RS. DUE 10 
DEMONSTRATION AT AFCD 


Discrepancy: a difference in the scheduied arrival time 
and a note concerning carrier deviation which only shows 


at cne site 


The need for complete, accurate, timely inrfzorma- 
tion is often taken for granted. In the CPE envircnment 
this requirement is even nore challenging since all partici- 
pating ccmmands need to be working with identically updated 
data bases if they are to make valid assumptions for plan- 


ning and executing orlans. 
d. Data Base Management 


"There is also a requirement to develop a system to restrict 
access tc data and restrict the capability to change data 
elements within JDS," [Ref. 11: pe 2-10]. Safeguards to 
prevent unathorized changes to data elements ir the JDS are 
insufficient. An authorized JDS user with modify pernis- 
sions may make unauthorized modifications in the data pase 
Since individual types of changes or types of data elements 
are insufficiently safeguarded. 

A change or update to the JDS data base using 
one update module пау ог may not update relevent  corre- 
sponding data elements. For example, ic a Carrier is 
reported as sunk using one update module a query module to 
display ships arriving on a given date may still display the 
ship as scheduled to arrive. 

"A major problem facing the deployment community 
is the lack of standardization of data elements between the 
JOPS, JDS, UNITREP, and OPREP. Because of the need tc acco- 
modate the interface with these systems, JDA has been forced 
ЕО pick and choose between various data elements, 
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ШОО Се апа $ormats," [ Ref. 11: р. 3-8]. The foilowins 
are scme of the problems resulting from the attempt to 
interface these systems: 
- data elements which actually have the same meaning 
have different names (e.g. different versions of an 


airfield name asscciated with the same location code) 


- data elements wnich have the same meaning may have 
different units or te calculated using different algcr- 
ithms (e.g. weight reflected in long tons on one system 


and shcrt tons on another) 


- data elements which have different meanings have the 

same names (e.g. arrival date on one system may Ге the 

time a unit will arrive in theatre, on another system it 

may be the time a unit will arrive at port of dekarka- 

tion) 

As the data base structure or the basic software 

of the 225 changes, the command unique queries written to 
run against the JDS data base must aiso be cnanged. 


С. REQUIREMENTS 


Gee vuly 1983 the Joint Chiefs of Staff approved the 
Joint Operation Planning and Execution System  (JCPES) 
Required Operational Capability. The initial operational 


concert, 


"Addressed procedures supported by state-of-the-art AD? 
Sapabilities which wculd result TA producing 
Capability-constrained courses of action ina matter of 
hours and completed en cr Eu uSomRced wıth actual 
units tested against deployment and sustainment capabil- 
meres, within days, These criteria, once achieved, 
represent a: revolutionary кар гогепепь to present plan- 
ning system capabilities. Prefs 9]. 
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Msi tenyvisvoned as, "Тһе foundation for our ccrnven- 
tional ccmmand and ccntrol system," and will accomplish its 
functions, "through the interoperation of a central ccre of 
Bernt applications and various C2 and functional systens .. 
. JOFES rust support the planning and execution of multi- 
theater scenarios involving total commitment of U.S. and 
МШ еа forces," (Ref. 12]. | 

JOPES will effectively replace the JOPS and JDS which 


today support CPE. JOPS and JDS are two separate systens 
which do not have an automated interface. JOPS is used for 
planning and JDS for execution. In МЧОРЕ5, scftware 


supporting these functions would not require the  ranual 
interfaces required today. Inzaddıtıon, JOPES will be 
required to share data with command unigue applicaticns 


which support CPE. 


"JOFES consists of the policy, procedures software, 
hardware, personnel training, and connectivity necessary 
to facilitate Tanning directing coordinating, moni- 
Gorgas СОВЕТ О ПВ nilitary operations." [Ref. 9: 
p. | 


For JOPES tc work effectively the WWMCCS community will Lave 
to develop and support a distributed data base concept which 
will perzit interfacing command unique software and systen 
standard software. In a distributed data base, porticns of 
the data are stored cn different computers. The physical 
location of the data ideally does not affect processing and 
is usually not even apparent to the user. This would elimi- 
hate the need for synchronizing multipie copies cf data 
Lases (except these required for reduadancy). Such an envi- 
ronment would also eliminate the manual manipulation of data 
currently required in interfacing the existing systems which 
Support CPE. 
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IV. RECOMMENDATIONS 


А. CHANGING ENVIRONMENT 


The current state of the art in automatic data 
processing ciferS many management and technical opportuni- 
ties to facilitate the transition from the WWMCCS Standard 
ADP of tcday to the kind of system required to support the 
evolving needs of the CPE environaent. The requirement to 
Share data among cormands in support of CPE requires addi- 
tional techniques and facilities not required by a single 
Site operating in isolation. Ihe Open System Interface 
reference model  prcposed by tne International Standards 
Crganizaticn provides a means to describe and docurent the 
interfaces required in a computer networking environment. 
The capatilities provided by local area networking cffer the 
facility tc link internal ccmmand resources together in 
support of command unique recuirements. The WWMCCS 
Information System is the onging ;rogram to modernize WWMCCS 
ADP utilizing modern technology to meet evolving require- 


rents. 
1. Cpen System Interface Reference Standard 


The International Standards Organization (ISO) 
Eroposed the Open System Interface (OSI) Reference Model to 
serve as a standard set of network interfaces and prctocols. 
The use of the 0SI Feference Model would be a step toward 
international standardization of the various protocols for 
distributed processing networks. Compatibility amorg 
network nodes would Ге assured by compliance with standards 
even when software and hardware at various sites are 
supplied by different vendors. 
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The OSI stancard is based оп а seven layer concept. 
Fach layer provides a portion of the services required to 
interface ncdes in the network. By breaking the interface 
problem intc seven layers, the implementation of different 
porticns of the interface can be developed, tested, fielded, 
and mcdified independently. The layered approach helps to 
isolate the functicnal requirement from the engineering 
implementation. As more efficient technology becomes avail- 


able the implementation cf a specific portion cf th 


iD 


interface can be changed withcut undue influence on th 


(D 


Ecers' interaction with the overall information network. 

The bottom three layers of the OSI model are host to 
imp protocols and the top four layers are host to host 
ppotoccls. Only the top two layers deal with interfacing 
user applications and data. 


LAYER 1: The Physical Layer supports the actual ccmmuni- 
caticn cennection between hcs*ts and the transmission of 


raw data cver the established channel. 


BAYER 2: The Data Link Layer ensures data received is 
errcr free and the appropriate acknowledgements are 
sent. 


LAYER 3: The Netwcrk Layer, sometimes called the commu- 
mreaticn subnet layer, is responsible for point to point 


routing of data between its origin and destination. 


LAYER 4: The Transport layer, also called the Hos-t-Host 
layer, is concerned with dividing the data into packets 


For transmission. 


BAYER 5: The Session Layer provides the capability for 
users cf different machines to establish a connection 


between processes on the machines. 
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LAYER 6: The Presentation Layer manages the exchanges 


ch 


© 
data between applications anywhere оп the network. I1 
ensures tte data is in appropriate format for the appli- 


caticn to which it is being sent. 


BAYER 7: The Application Layer provides the interfaces 
between user and application and the user and the 


system. 


Layer 
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Figure 84.1 Netwcrk Based on ISO OSI Reference Model. 
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Figure 4.1 [ Ref. ise pees 167, illustrates a network 
based on tke ISO OSI Reference Model. The dotted lines 
represent virtual ccrnectivity between similar layers on 
different hosts while the solid lines represent physical 
connectivity. The ISO OSI provides a useful way of 
describing protocols which perform required network func- 
tions while leaving the engineering of the imolementaticn up 


to the netwcrk designers. 


2. local Area Networks (LAN) 


= сағ 


Local area networks (LAN) are networks which grcvide 
high speed communications among information processing 
equipment in a limited geographic area. Local area networks 
have evclved from previously existing methods of networking 
and ccmmunicating. They provide the capability to interface 
Many kinds cf devices and to exchange data with other LANs 
or long haul networks. In general, LANs offer high data 
transmission speed at lowered costs wnile sacrificing long. 
distance data transmission capability. LANs area key 
element in the strategy for the WWMCCS Information System. 
Attributes of LANs which are being evaluated for support of 
WIS include: 

flexible topolcgy 

security 

expandability 

flexibility in selecting transmission media 


reliability. 


3.  XWMCCS Informzation System (315) 


"The WWMCCS° Information System (WIS) encompasses the 
Enrcrmaticn collection, т and display ccn 
that includes WWMCCS ADP and related software systems, 
procedures, and supporting teleconmunications. The 
Modernization, focus is ðn the. backbone of standard 
WWMCCS ADP which supports command systems . .. The JPM 
(Joint Progran Bae E) focus will be on software and 
data management techniques." [Ref. 14: p. ES-1 
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The WIS is explained triefly in order to shed some light on 
the current effort to improve WWMCCS ADP which wili affect 
the ADP environment in which CFE users operate. Тһе surpcrt 
provided by WIS will be implemented incrementally.thereby 
providing evolutionary modernization. This will help mini- 
mize the overail impact on command and control users while 


permittirg advances in computer technology to be utilized. 


"The KIS JPM task is to modernize and enhance the 
Eosmpnand cchtrol software, acquire state-of-the-art hard- 


ware and add capabilities, to the command control 
сез». These capabilities include automatin tne 
andling of operaticnal messages, distributing data and 


enhancing the capakility of command control personnel to 
interact with their information." (Ref. 15: р. ] 

Figure 4.2 [ Ref. 16], illustrates the capabilities 
to be provided by WIS. In implementing WIS one goal is to 
Maintain the separation of the the engineering iuplementa- 
tion fron.the desired capabilities. In other words, varicus 
commands may use different hardware and software to support 
their sites. Ine addition; LANs will provide tailored 
support fcr internal requirements of commands while still 


permittirg and interface with the long naui network. 


4. 


кл 


ummary 


PES ae SS 


The recurring emphasis in state-of-tne-art ADP tech- 
nology is interfaces which permit the Separation of 
engineering and function. This should permit the users to 
select tte implementation best suited to their needs and 
still interact witk other users supported by different 
inpleientations. This conceptually permits systems то 
continue to grow and evolve, making use of new technolcgy 
withcut disrupting the supported functions. 
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Figure 4.2 User Capabilities Supported by WIS. 


32 





E. STANLARDLIZATION - A NEW APFEROACH 


Ihe growing requirement for automated interfaces between 
the prograns and data bases used by different commands to 


роге СРЕ cannot Ге supported using tae current  WUMCCS 


Seandard Software. If commands want to interface software 
boday, the interfaces must be designed individually and 
uniquely tailored to the two ends of the interface. Figure 


4.3 illustrates the interfaces which would be required to 
link the software of four members of the joint deployment 
conmunity today. Each line represents a specific interface 
developed Eetween applications at two commands. In this 
example six programs are required to interface each oí tae 


four ccmrands to each of the other three. : 


а ыы” нин MD | 


О eee OC 


| 
| 
| 
| M AC IT IC | 


Figure 4.3 Interfacing under WWMCCS Today. 








It is clear that in addition to necessitating many nan- 
years of software development, an interface would reguire 
updating each time an application on one end was mcdified. 
Ihe requirement still exists, however, to share data ancng 
commands. In JOPES, 


"Once an ыыы agency updates its data base, the 
distributed data ase concept will permit automatic 
updating, іп summary format, of all interrelated data 
bases . . .. JOPES will not burden lower level staffs 
with extensive reporting requirements but will interface 
with ccmmand and agency-unique systems as necessary and 
within owner SS Lees to Laplaly obtain 1пгогпа = 
meen.” [Ref. 9] 
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JDA has made progress with near real-time updating of data 
tases located at different commands but the JDS requires all 
participating commands to be using exactly the same JDS 
software, operating on the same WWMCCS Standard Hardware. 
This approach does nct permit the interfacing of ccmmand 
unique applications and data bases among commands. 

In order to obtain the benefits of timeliness and accu- 
гасу іп interfaces, an ADF solution is preferable tc the 
current manual interfaces. If the WWMCCS community would 
define a core set of data which is required for СРЕ апа 
standardize the description cf this data, each command 
seeking to interface with another command would only have to 
develop an interface ketween the standard data set and their 
command unique software. Figure 4.4 illustrates the Joint 


Teployment Community interfacing in this manner. 


РИК НЕЕ 7-22 e E ----- Гете 1 
| | 
| | 
{ 

| JDA MSC | 

Pom 

| INTERFACE | 
| MAC ИС | 
A ж —_——._.—..—.._—_—_——_—_.—_.—_—_——.—.—..—_—_..——_—3 


Figure 4.4 Interfacing through a Standard Data Set. 


The total number of interfaces would be reduced signifi- 
cantly and each ccmmand would only have to plan спе 
interface with the standard data set in order to interface 
ap application with all other participating commands. In 
this example the total number cf interfaces was reduced from 
ОКЫ to four by ЕП through a standard data set. 
More impcrtant, each node new only requires one interface 


vice the three previously required. The use of a ccmmon 
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interface permits many widely separated data bases to func- 
tion virtually as a distributed data base. This will nein 
meet the identified requirement for a distributed data base 
approach tc support JOPES. Tt 52s not a distributed data 
base in the routine sense but rather an interface which 
permits the exchange of data among separate data bases. 
This ccencert is furtker developed in a later section. 


H 


NE tectrorie Data Interchange (ZDI) 


а. Background 


urhe U, E. Electronic Data Interchange  (ZLI) 
Standards are designed to facilitate the electronic irter- 
change of data ina standard manner between independently 
organized, cwned and/or operated computer and communicaticns 
systems," [ Ref. 17: ғ. 9). The EDI standards were devel- 
oped in an extensive joint government-industry effort to 
meet a recognized need in the transportation industry for 
timely, reliable trarsmission cf data among organizations. 


The Organizations utilizing the EDI standards include: 


Motor Carriers 

Ocean Carriers 

ATI Carriers 

Railroads 

Brokers 

Shippers 

Benscigrees 

Freight Forwarders 

Freight Ccnsolidatcrs 

Banks 

Agents | 

U.S. Custcms Service . 

UNES Departnent of Agriculture 
EN. oeneral Services Administration 
U.S. Department of Defense. 
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Іс МЕГШеЕБРЦЕЕ ОСТЕРІ 


The major unit of information in EDI is the 
transaction set. Transaction sets support tne major func- 
tions performed Бу the communicating organizations. 


Information units in the EDI include: 


"Data Element: The smallest information unit in the EDI 
infcrmation structure is the data element. A даса 
element may bea, single character code, a, series of 
Ehnaracters constituting a literal description, or a 
numerical quantity. 


Data Segment: A data segment is composed of a furction 
identifier and one or more .functionaliy related data 
elements positioned serially in a standard manner .. .A 
segment is roughly equivalent to a line of information 
ШЕ Dili of lading or freight bill. 
meansacticn Set: A. transaction set is a group oT data 
ШО aen a predfined zeguenee, needed tö provide all 
of the data required to define a, complete transaction 
sen aS shipment information or invoice . The transs: 
action set ın EDI кее to a document ina paperwork 
system, such as a rill of lading or invoice. 
Functicnal ,Grcup cf Transaction Sets: nr unctrional 
fie oe 1dentifies these transaction sets of the зале суре 
е a 
( 


urina the same indentifier and subject ti 
Ref. 18] 


Figure 4.5 [Ref. 19], Shows how the information units are 
put together to build a complete transaction set., The first 
data segment shown in the second column of the example is 
composed cf the first four data elements in the first 
colunn. This same data segment becomes the first part of 
the transaction set in column three. It should re noted 
that a Gata element (e.g. А) can be used in more than cne 
data segment. 
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Figure 4.C [Ref. 19], shows how a communicaticns 
session with a user inputting data into the netwcrk can 
include more than one transaction set. This figure fcllows 
fhe building block approach by showing that related trans- 
acticn sets (e.g. purchase orders) сап te regarded asa 
functional group and several related or unrelated functional 


groups can te sent in the same transmission. 
C. EDI Operations 


The EDI ccncept operates through the use of five 


tables. 


"The same five tables are used for generation of data tc 
be transmitted and for the interpretation of data that 
is received. The set of tables defines the structure 
and attritutes of the EDI transaction sets,  segnents, 
data elements, and codes. ihe EDI operational software 
programs control  rcinters to these ables and use the 
PerOrnmation at the pointer locations, in combination 
with data from the user's data base, to assure program 
generation and interpretation of data." [Ref. 193 


Ihese tables are used to process incoming and outgoing data. 
Figure 4.7 [Ref. 19], explains generally how the tables are 
used. Figure 4.8 [Ref. 19], presents a more detailed 
example of the data structure, with sample entries for each 
table described in figure 4.7 Table 1 has a list of all 
transaction sets with identirying numbers. Table 2 lists 
the data segments in each transaction set. Table 3 isa 
directiory of all data segments with identifying nuuters. 
Table 4 lists the data elements in each data segment.  Tarle 
5 1s tke data dictionary and is broken down by data 
elenents. Detailed examples of eaca table are given ina 
later section.. 
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Figure 8.6 A Communications Session. 
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Table 1 is used to locate items in Table 
2 


Table 2 gives the order of segments in a 
transaction set for each application. 


Table 3 is used to locate items in Table 
4. 


Table 4 gives the order of data elements 
in each segment. 
Table 4 example (simplified): 


Segment I.D. Data Element Location 


(Example) 


Table 5 specifies data element attributes. 
Table 5 example (simplified): 


Data Element Maximum Lenath 
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Figure 4.7 Use of Tables in EDI. 
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d. Advantages of EDI 


The emphasis in the EDI concept is on communica- 
tions (exchange of information) between computers. BY 
communicating through the use of standard transaction sets, 
EDI permits users to interface efficiently while preserving 
their autonomy. Each user could conceivably be using 
different kinds of hardware, software, and data base aanage- 
ment systems andstill be akle to communicate. An added 
Lenefit cf the EDI approach is that data elements can be 
added or deleted withcut requiring software logic changes. 
ИЕ) Changes ina user's applications will not affect the 
interface with other users as long as the translaticn tc the 
EDI standard is updated within the command. 

The EDI ccncept could be used within the WWMCCS 
community tc ease the transition to the distributed data 
Басе environment which will be required to support CFE. ШО 
implement this approach, members of the WHMCCS cenmunity 
would have to define the applications and the data which are 
required to support CEE. Sstandardenetsods тос data ccenterol 
would te required. Once the standards were developed and 
documented it would te the responsibility of each cormard to 
make the translation between their applications and the 
Standard.  Cnce all tbe involved commands are able tc trans- 
late between their applications and the standard, they could 


also ccmmunicate directly with cther participating ccmuands. 


2. ApEiication іс Specific Brobleas 





The desirability of implementing the EDI ccncept 
Within the WWMCCS ccmmunity can be evaluated by examining 
how it would help resolve the some of the problems which 
have been identified in WWMCCS ADP support of CPE. 
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a. Data Base Managenent 


In order to ensure the accuracy of data the 
capability to modify cr delete data must be controliec. The 
current system dces nct protect against unauthorized changes 
made ky a user who is authorized access to some but not 
neccessarily all data. The EDI concept would contribute to 
security because the data elements would be distrituted 
among the ccmmands with ultimate control and modify pernis- 
sions held Ey the command "owning" the data and responsitle 
for its accuracy. Another command could request, data kut 
the system would ckeck to validate the identity of the 


sender, in accordance with pre-arranged agreements, 


"The ccmmunications protocol provides a means for posi- 
tive identification of the sender by the receiver, and 
conversely . . . Lug of tránsmissions which dc 
not pass the comnmunication header validation tests is 
aborted after an error reply is sent to the sender and 
the conditions have been logged for subsequent study or 
analysis." fRef. 17] 


By distributing the data and controlling communicaticns 
access tc specific data, the EDI concept provides more secu- 
tity than the current systen. 

In the current system a change or update to the 
JDS data base using cne update application may or may not 
update relevent corresponding data elements. Using the EDI 
approach, many applications could rely on a single ccry of a 
data elesent so the cpportunity for discrepancies would be 
minimized. Today different applications use different files 


and it is difficult tc effectively update all instances ofa 


data elenent. In addition, through use of the transaction 
sets, groups. of related data elements could be updated 
together. 
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НЕ ЕЛСИ аск от Standardization of data 
elements among standard and Command unique systens сап be 
significantly reduced through the use of the EDI concert. 
Initially an effort would te required to identify data 
elements which must Ге shared among members of the WWHCCS 
community. The definitions of these data elements would be 
specified and incorpcrateä into a standard. Each ccrmmand 
which needs to interface with another in tre community would 
then develop the necessary software to translate command 
data elements into the standard format. "The interface 
computer pregram and the structure of each type of trans- 
action set are part of the EDI standards. EDI does not 
address a standard which extends into a company's internal 
system," (Ref. 171. The EDI sortware would perfcrm the 
functions which would facilitate interfaces among partici- 
rating ccmmands. Cnce data to be interchanged has been 
defined in a standard definition, individual commands can 
convert data elements to the standard through individual 
software rcutines. This would resolve the following kinds 
of discrepancies: 

- data elements which actually have the same meaning 


have different names 


- data elements which have the same meaning may have 
different units or ke calculated using different algcr- 


ithıs 


- data elements which have different meanings have the 
same nanes 
As the data base Structure or the basic software 
of the JTS changes, the command unique queries which rely оп 
the 225 data base often must be rewritten. The EDI ccncept 
is designed, 


"Tc respond with ease to frequent requirements for modi- 
ereaticon, contraction, and/or expansion of the 
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individual applications. : : the ingormaticn is 
structured so that 1t may be constructed by one computer 
system and interpreted and processed by another, New 
applications апа information units mE be specified 
without аск work previously completed." [Ref. 17: 


Pip. 6-13 


The physical implementation (e.g. the programming languages 
and the data base management system) of any standard or 
unique application is kept isolated from the standard data 
definitions so modifications to implementation methodology 


wili not destabilize the system. 
Е. Data Base Inconsistencies 


The problem of different sites having different 
copies of the data tase would be avoided through the EDI 
concept because of the distribution of data. Each data 
eienent would reside at the command responsible for its 
accuracy but would Fe accessible to other commands. Even 
with provision for redundancy this is still a more desirarle 
arrangement than multiple copies of data bases residirg on 
many systems at many locations. In this vay, as data 15 
updated for one purpose (e.g. UNITREP) the updated data 
would also te availatle for other applications such as JCPS 
or 405 withcut requiring separate updates for each applica- 


tion. 
С. . NOPLAN Surport 


The use cf the EDI concept could helg in a 
NOPLAN situation by eliminating tne necessity to send copies 
of entire data bases cr lengthy messages among commands. As 
each ccrrand successively develops a portion of the plan, 
data can be extracted from applicable data bases, incorpo- 
rated into transaction sets and transmitted tc  cther 
involved ccmmands. Because the construction oí new 
instances of a transaction set can be facilitated by the EDI 
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tables it would be much easier for commanders to evaluate 
varicus alternatives since less data would have to Le sent 
among commands to generate responses to "what if " ques- 
tions. It would alsc be possible to inciude as part of the 
information on a specific unit tne various OPLANS in which 
the unit was tasked. This could ре done by developing a 
data segment which includes as data eiements the unit desig- 
nation ard the plans which task it. In this way potential 


problems with multi-tasking could be identified quickly. 
d. The Interface Between JOPS and JDS 


The interface between JOPS and JDS, and other standard or 
command unigue applications could be significantly sinpli- 
ted” through the EDI CONCEPT. Since incompatibility of data 
elements is not a prcrlem when the common interface is used, 
data frcr numerous systems could be tapped in response to 


information queries input using any one of the systens. 


С. IEPLEMENTATION 


Although the EDI concept requires a standard set of data 
elements in order to cperate, there is no centralized stan- 
dard data base. EDI facilitates the transfer of data among 
various data bases by means of a common interface. Laying 
the  groundwork for an EDI interface is in some ways, 
however, siailar to data base design. Іі will be helpful to 
examine the necessary preparation for implementing ЕГІ іл 
data kLase design terıs. 

A data kase is a model of an organization which exists 
in the real world. Events which occur in the real world are 


reported to the data base system as transactions which in 


turn cause data to be modified. Design considerations for 
data Lases as models are listed in figure 4.9 [Ref. 20: p. 
1771. 
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Database as a model of an enterprise 


Level of detail 
Cost of aggregation and generalization is unanswerable question 
Need to aggregate and generalize in light of requirements and 


financial resources 


Dynamics of database as model 
Enterprise changes, model must change 
Events occur, are represented by transactions 
Level of transaction important - transactions cannot be more 


aggregated or generalized than database data 


User views 
Different perception of data structure 


Different perception of data meaning 


Need for standardized meaning 
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Figure 4.9 Design Considerations for Databases as Models. 


The fact that in CPE users represent many commands with 


different views can cause a design problen, 


"Different users (and desianers) will have different 
neanings andesineerrretetrons for data that is stored ir 
the datakase, Questions that appear to be sinilar may 
in fact be different." [Ref. 20: р. 177] 


Definition cf a set of data elements which must be 
available in an EDI interface would require a great deal of 
effort with high level support in the joint arena. The 
standard data elements will be the building blocks from 


which interfaces will be constructed. 


' Data base design is divided into two phases: , logical 
design, where the needs of people are specified, апа 
physical design, wkere the lcgical design is napped TREO 
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Бе сспетгатптс сі р 
Products,” [Ref. 20: р. 


о: program and hardware 

The lcgical data base design is aone by the users whc need 
to use tke data. The physical data base design is normally 
done by experts skilled in evaluating aardware and scítware 
capabilities and selecting the most feasible means of imple- 
menting the logical design, This division of effort would 
apply also in a general way to designing a standard EDI 
interface, although it is not a data pase management system 


рег se. 


1. Iogical Data Ease 


Ф 
ic 
(n 
{Л 
үз 
la 
ГЕ) 


â. The Output 


The output of a logical data base design isa 


schema which defines the data records (in EDI terrinology, 


the data segments) which are to be maintained, the data 
elements which compose then, and the relationships among 
these data segments and data elements. Data segments are 


descrited by listing the data elements which they contain 
and constraints which limit the values the data can have. 
Transaction sets, in turn, are described by listing the data 


segments they contain and applicable constraints. 
Е-Е Input 


The inputs of the lcgical data base design are the system 
requirements and the plan which describes the envircnnent 


and constraints, which will affect the system. 


С. Procedures 


"The rajcr steps in the logical design process: 


E data to Ге stored 
consclicate and ges Me data names 
develop the logical schen 

define Poe scm 

review design," век. 20: р. 181). 
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In the process of identifying the data tc be 
stored, the data dictionary is developed and Jata elenents 
are identified by name and described. Figure 84.10 
(Ref. 18”, is an example of a portion of an EDI data 
ret ionary. To see now the data dictionary is set up, 
consider data element "10" in the left column. Data element 
"10" is defined as a six digit numeric field which is 
entered with tne first two digits representing the last two 
digits of the year, the middle two digits representing the 
nonth, апа the last two digits representing the day of the 
month. Ms cal description OL the data element is 
also acccmpanied by a verbal definition of the data element. 

To consclidate and clarity data names it is 
necessary to identify synonyms and aliases. Synonyms are 
different names for the same data element. Synonyms should 
ke reduced to one standard name. Aliases are alternate 
names for the same data element (synonyms) which are 
permitted to remain in the systen. ZDI eliminates the need 
for aliases because, although different users may have 
different names for the same data element, they can prcvide 
for "translation" to the standard by means of the software 
they design to interface their unique system to the EDI 
standard. 

The develcpment of the logical schema consists 
of defining data segments and their relationships. Figure 
4.11 and figure 4.12 are samples of two EDI tables which 
list data segments and the data elements from which they are 
built. [Bef. 19]. In Table 3 (figure 4.11) the data 
segment titled "beginning segment for completed payments" is 
assigned the segment ID number "B7". This data segment is 
composed cf three data elements (see the right  colunn). 
These data elements can be identified using Table 4 (figure 
4.12) by finding the segment ID number "57" in the first 


column. The seccnd column lists each data element 
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————————- S! 


DATA ELEMENTS 


2 ACCEPTED SETS 
(SPEC: ТҮРЕ» М MIN" 1: MAX. 3) 
NUMBER OF TRANSACTIONS RECEIYED WITHOUT ERROR IN A 
FUNCTIONAL GROUP (NUMBER MAY BE 0) 


REFERENCE OESIGMATOR(S): 8502 


3 FREE-FORM MESSAGE 
(SPEC: ТҮРЕ» AN 
FREE-FORM TEXT 
ALSO SEE: MOTE REFERENCE CODE (363) 


REFERENCE DESIGNATOR(S): К201 NTEOZ 


MIN» 1; МАХ» 60) 


8 ARRIVAL DATE 
(SPEC: TYPEs N MIN» 6; МАХ» 6) 
DATE (YYMMDO) AS REQUIRED BY CUSTOMS 
ALSO SEE: ЕТА OATE (45) 


REFERENCE OESIGMATOR(S): X302 


7 BANK ACCOUNT NUMBER 


(SPEC: ТҮРЕ» М MINs 6: МАх» 17) 
ID NUMBER ASSIGNED BY BANK TO ITS CLIENT 
REFERENCE DESIGNATORI(S): C205 
8 BANK CLIENT CODE 
(SPEC: ТҮРЕ» 4 MIN» 1; МАХ» 1) 
IOENTIFICATIOM OF PAYEE OR PAYER: 
CODE OEFINITION 
E PAYEE 
В PAYER 
REFERENCE DESIGNATOR(S): C201 
9 BANK PLAN NUMBER 
(SPEC: ТҮРЕ» М MIN» 1: МАХ» 6) 
NUMBER ASSIGNED ЗҮ SANK TO PAYER'S FREIGHT PAYMENT 
ACCOUNT 
REFERENCE OESIGMATOR(S): 8605 8702 


10 BANK TRANSACTION DATE 
(SPEC: ТҮРЕ» М MIN» 6: МАХ» 6) 
ОАТЕ (ҮҮММОО) THE BANK RECORDED THE TRANSFER OF 
FUNDS 


REFERENCE OESIGNATOR(S): 8703 


11 BILLING CODE 


(SPEC: TYPE. A MIN» 1; МАХ» 1) 
TYPE OF BILLING REQUIREMENT FOR MULTIPLE EQUIPMENT 
SHIPMENT: 
CODE DEFINITION 

A TEMPORARILY ARTICULATED LOAD 

М MULTIPLE SHIPMENT BILLING 

О MULTI-CAR TRANSIT 

R RULE 24 LEAD AND TRAILER EQUIPMENT ON 

SINGLE REYENUE BILL 

S SINGLE SMIPMENT BILLING 

Т TRANSIT BILLING 

U UNIT TRAIN BILLING 


REFERENCE DESIGNATOR(S): 8211 


12 BILLING DATE 
(SPEC: TYPE= N МІМ“ 6; МАХ» 6) 
DATE (YYMMDO) OF THE CARRIER'S INVOICE 


REFERENCE DESIGMATOR(S): 8306 СОО» R503 


13 BDOKING NUMBER 


(SPEC: TYPE» AN HIN» 1; МАХ» 10) 
NUMBER ASSIGNED BY THE CARRIER FOR SPACE 
RESERVATION A 


REFERENCE OESIGNATOR(S): Y301 Y401 Y50i 


14 CARRIAGE VALUE 
(SPEC: ТҮРЕ» М MIN® 2; МАХ» 3) 
CARRIAGE VALUE EXPRESSED IN WHOLE UNITS OF THE 
STANOARO MONETARY OENOMINATION FOR THE CURRENCY 
SPECIFIEO (IMPLIED O€CIMAL POINT IS TO THE RIGHT 
OF THE EXPRESSED VALUE.) Í 


REFERENCE DESIGNATOR(S): M102 


15 CARR CERTIFICATED REL. DATE 
(SPEC: ТҮРЕ М MIN= 6; МАХ» 6) 
OATE (YYMMDO) OF CARRIER'S CERTIFICATE OF RELEASE 
AS REQUIRED BY CUSTOMS 


REFERENCE DESIGMATOR(S): X303 


18 CHARGE METHOD OF PAYMENT 
(SPEC: ТҮРЕ" A MIN" 1; МАХ" 1) 
COOE OEFINING METHOD OF PAYMENT: 


CODE OEFINITION 
A PREPAID CASH 
8 PREPAIO CREDIT 
C COLLECT CASH 
D COLLECT CREDIT 
Е COLLECT 


REFERENCE OESIGWATOR(S): Lili (811 


19 CITY NAME 


(SPEC: TYPE». АМ MIN= 2: МАХ» 19) 
FREE-FORM TEXT FOR CITY NAME 
REFERENCE OESIGNATOR(S): 0401 0701 E401 £701 
F401 F701 F906  H502 
L715 М401 NAMOS RINOS 
5402 5903 1209 7210 
1604 1607 2103 (401 
901 У906 Ү10% 
20 CLIENT BANK NUMBER 
(SPEC: TYPE» N MIN» 3: MäX= 9) 
FEDERAL RESERYE ROUTIMG CODE (SEE APPENOIX А-АА) 
REFERENCE DESIGNATOR(S): C204 
21 C.0.D. CURRENCY 
( SPEC: TYPE» A MIN» 2: MAX» 2) 


STANDARD ISO CODE FOR THE COUNTRY IN WHICH THE 
C.0.D. CURRENCY IS SPECIFIED (SEE APPENDIX 4-45) 


REFERENCE OESIGNATOR(S): C305 C701 
22 COMMODITY CODE 
(SPEC: ТҮРЕ» AN MIN® 2: МАХ“ 10) 


ALPMA/NUMERIC CODE USED TO OESCRIBE A COMMODITY OR 


GROUP OF COMMODITIES FOR RATING AND BILLING PURPOSES 


ALSO SEE: COMMODITY COOE QUALIFIER (23) 
€607 1503 1903 
IROS 180% 1907 
9701 М0111 м203 


REFERENCE OESIGWATOR(S) : 1RO4 


TD104 


23 COMMODITY CODE QUALIFIER 
(SPEC: TYPE» 4 MIN» 1: МАХ» 13 
QUALIFIER FOR THE COMMODITY CODING SYSTEM USED TO 


OEFINE THE [ТЕН LADING OESCRIPTION (SEE APPENDIX A- 


A6 THRU А13, A33) 


CODE OEFINITION 
A SCHEDULE A, TARIFF SCHEDULES OF THE 
UNITEO STATES ANNOTATEO 


8 U.S. FOREIGN TRAOE SCHEOULE B, STATISTICAL 


CLASSIFICATION OF DOMESTIC ANO FOREIGN 
COMMOOITIES EXPORTED FROM THE UNITED 
STATES 

CANAOIAN FREIGHT CLASSIFICATION 

COOROINATEO MOTOR FREIGHT CLASSIFICATION 

BRUSSELS NOMENCLATURE HARMONIZED SYSTEH 
( MARMONIZED 8TMN! 

MUTUALLY OEFINEO 

NATIONAL MOTOR FREIGHT CLASSIFICATION 
(NMFC) 

STANOARO INTERNATIONAL TRADE CLASSI- 


xI Im 
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Figure 4.10 
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associated with the data segmert and the third ccluan indi- 
cates whether the data element is mandatory (4),  optionai 
(O), Oi cea опа о Additioral informatici 15 
contained in the remaining columns. These tables are used 
in cenjunction with the data dictionary which descrites 
individuai data elements, to form the logical schema. 

To define processing, transactions should Бе 
defined. Transacticns represent events in the real world 


and in ELI transacticn sets represent paperwork which docu- 


ment a real world event. Transaction sets are defined in 
terms of the data segments from which they are built. ina 
sense this is an extension of tne logical schema. Figures 


4.13 and figure 4.14 are a sample of two EDI tables which 
list transaction sets and the data secments they include 
[Ref. 19]. In Table 1 (figure 4.13) the transacticn set 
prtled "flight  confirmaticn" is assigned set Ір пипіег 
101". This transaction set is composed oz eight data 
segments. These data segments can be identified using Takle 
ШИИ биге 4.114). By finding the set title "flight confir ua- 
Bron" and the set ID number "101". The second column under 
"flight confirmation" lists each data segment associated 
with the transaction set and the third column indicates 
whether its use is  randatory, optional, Or conditicnal, 
Additicnal informaticn is provided in the remaining colunns. 

The purpose of a design review is to identify 
flaws. Dccumentaticn from the previous stages is examined 
and prcrlems are identified and recommendations for resolu- 


tion are made. 


A 


Le 


ікі 


jySical Data Base Design 


Since EDI is nota data base management system as 
such, tne steps of physical data base design apply only ina 
loose sense. The physical design differs from the logical 
design primarily in the sense that the physical schena 


provides for the implementation of the logical schema. 
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TABLE 3 - 'SEGMENT NAMES 


TABLE 3 - SEGMENT NAMES 


Segment Name 


CONTROL HEADER (FUNCTIONAL GRDUP) 

CDNTRDL TRAILER (FUNCTIDNAL GRDUP) 

ENDING SEGMENT (TRANSACTION SET) 

STARTING SEGMENT (UCS TRANSACTION SET) 

REJECTION 

BEGINNING SEGMENT FDR MANIFEST 

BEGINNING SEGMENT FOR BDDKING DR PICK-UP/DELIVERY 
BEGINNING SEGMENT FDR SHIPMENT INFDRMATIDN TRANSACTIDN 
BEGINNING SEGMENT FDR CARRIERS INVDICE 

BEGINNING SEGMENT FOR INQUIRY DR REPLY 

BEGINNING SEGMENT FOR ACCEPTANCE/REVECTIDN 
BEGINNING SEGMENT FOR PAYERS AUTHORIZATION 
BEGINNING SEGMENT FOR COMPLETED PAYMENTS 
BEGINNING SEGMENT 

BEGINNING SEGMENT FOR REPETITIVE PATTERN MAINTENANCE 
BEGINNING SEGMENT FOR ADVANCE CONSIST 

BEGINNING SEGMENT FOR FILE TRANSFER INFORMATION 
BEGINNING SEGMENT 

FREIGHT PAYMENT . 
CDMPLETED PAYMENTS 

BANK ID 

CURRENCY 

CDMMERCIAL INVDICE TDTAL PRICING 

CDMMERCIAL INVDICE CERTIFICATIONS AND CLAUSES 
CDNSIGNEE NAME 

CONSIGNEE ADDRESS 

CDNSIGNEE CITY 

CDNSIGNEES THIRD PARTY 

CDNSIGNEES THIRD PARTY ADDRESS 

CDNSIGNEES THIRD PARTY CITY 

DELIVERY RDAD CDDE 

DESTINATION STATION 

DDCUMENT REFERENCES = 
EMPTY CAR DISPDSITION - PENDED DESTINATION CDONSIGNEE 
EMPTY CAR DISPDSITION - PENDED DESTINATION CITY 
EMPTY CAR DISPDSITIDN - PENDED DESTINATION RDUTE 
EMPTY CAR ADVANCE DISPDSITION 

CAR HANDLING INFORMATION 

BLOCKING AND RESPONSE INFORMATION 
EXCHANGE RATE/DRDER ACCEPTANCE DATE 
CDNSIGNDR NAME 

CDNSIGNOR ADDRESS 

CDNSIGNOR CITY 

CONSIGNDRS THIRD PARTY 

CONSIGNDRS THIRD PARTY ADDRESS 
CDNSIGNORS THIRD PARTY CITY 

DRIGIN STATION 

SHIPMENT TYPE INFDRMATIDN 

BEYOND RDUTING 

BROKERAGE INFORMATION 

GDODS DETAILS 

HAZARDDUS MATERIAL 

ADDITIDNAL HAZARDDUS MATERIAL DESCRIPTION 
SPECIAL HANDLING INSTRUCTIONS 

CAR SERVICE DRDER 

INVDICE TERMS AND CONDITIONS 
INVDICE ITEM LINE 

REMARKS 

ADMINISTRATIVE MESSAGE 

FILE INFDRMATIDN 

LINE ITEM - QUANTITY AND WEIGHT 
RATE AND CHARGES 

TARE WEIGHT 

TOTAL WEIGHT AND CHARGES 
MEASUREMENT 

DESCRIPTIDN. MARKS AND NUMBERS 
CARRIERS LINE ITEM REFERENCE NUMBER 
TARIFF REFERENCE 

LINE ITEM SUBTDTAL 

CHARGE DETAIL 

LETTER DF CREDIT REFERENCE 


- INSURANCE 


SALES/DELIVERY TERMS 

RELEASE 

CDNSCLIDATION MANIFEST INFORMATION 
MANIFEST LINE IDENTIFICATION DATA 
REPETITIVE PATTERN NUMBER 

SEAL NUMBERS 


Figure 85.11 
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List cf Data Segments. 


=А „А 


Data 
Elements 
(Table 4) 





| 
| 
| 
| 


| TABLE 4 -*DATA ELEMENTS IN EACH SEGMENT | 
| TABLE 4 - DATA ELEMENTS IN EACH SEGMENT i 
Баттал Data Require- Special Location in | 
D Element ment Process Master Record | 
хх 142 М о --> <-- 
хх 124 M о --> <-- | 
хх 29 м O --> <-- | 
XxX 30 M о --> <-- 
GE 97 М о --> <-- 
GE 96 C O --> <-- | 
GE 28 с о > <== | 
ЗЕ 96 M A16 --> <-- 
5Е 329 С А17 --> <-- | 
STR 143 M о --> <-- 
STR 329 e О --> <-- 
A 1 131 м о - => <-- 
А1 126 M о --> <-- 
А1 44 M о --> <-- i 
А1 43 М [e] --> Lan 
ВО 143 M О --> <-- | 
ВО 215 M о „=> <-> 
BO 214 M о --> <-- | 
BO 22B C о -- > <-> | 
BO 91 С о --> <-- 
В1 143 М © ^" <-- | 
B1 145 M о --> <-> 
B1 239 E о --> <-- | 
в2 143 M о --> <-- | 
B2 298 м О --> <-- 
B2 154 0 о --> <-- | 
B2 223 о E0405 --> <-- 
| B2 129 0 E0405 --> <-- | 
B2 145 0 о --> <-- 
| в2 18B C о Sex poe | 
B2 146 M о --> <-> 
в2 147 С О --> <-- 
B2 11 0 O --> <-- 
В2 226 0 о --> <-> | 
В2 195 о о --> <-- ( 
B2 199 0 о --> <<< 
B2 460 0 о --> <-- 
B3 143 M о --> <-- 
B3 76 M O --> <-> | 
B3 145 С о --> «-- | 
B3 146 E о --> <-- 
B3 1BB C О --> <-- | 
B3 12 M O --> <-- 
B3 193 0 O --> <-- | 
83 202 0 © --> <-- | 
. B3 32 о РОЯ 10 --> <-- 
B3 33 € РО910 --> <== { 
B3 140 С о --> <-> 
B4 143 M о --> <-- 
B4 157 С CON3 --> => 
B4 158 С о --> <-> 
B4 161 С о --> <-- 
B4 159 C о --> <-- 
B4 206 С CON7 --> <-- 
B4 207 e РОТОВ --> <-- 
BS 143 M о --> <-- 
BS 2 M O --> <-- 
BS 123 м о --> <-- | 
BS 2B M о --> <-- 
B6 143 M о --> <-- | 
B6 145 М о --> <-- 
BS 75 M о --> <-> 
B6 76 C о -- > <-> 
B6 9 6 о --> <-- 
B6 245 0 © --> <-- 
B6 249 e о --> <-- 
B7 143 M О --> <-- 
| В7 9 M Q --> <-- | 
87 10 M О --> <-- 
| ВВ 143 M о --> <-- | 
вв 128 E о --> <-->» 
BB 127 M О 52; <== | 
BB 125 M O --> <-- 
| BB 18B C о --> <-- | 


| 








Figure 4,12 Data Elements in Each Data Segment. 
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TABLE 1 - SET NAMES 


| 
| 


| 
| 
RE 
Set Name Set ID Se nt 
(TaBle 2) | 
FLIGHT CONFIRMATION 101 8 | 
SHIPMENT INFORMATION (AIR) 104 40 
CONTAINER/EQUIPMENT TRANSFER (AIR) 105 7 | 
SHIPMENT INFORMATION FOR EXPORT OECLARATION (AIR) 107 33 | 
SHIPMENT INFORMATION FOR IMPORT (AIR 108 37 | 
SHIPMENT INFORMATION FOR PICK-UP/OELIVERY OROER (AIR) 109 14 | 
FREIGHT OETAILS ANO INVOICE (AIR) 110 32 
FREIGHT OETAILS AND INVOICE SUMMARY (AIR) 111 8 | 
INQUIRY (AIR) 113 5 | 
SHIPMENT IOENTITIES ANO STATUS REPLY (AIR) 114 6 
STATUS OETAILS REPLY (AIR) 115 9 | 
REPETITIVE PATTERN MAINTENANCE (AIR) 116 33 i 
SHIPMENT INFORMATION (MOTOR) 204 31 
CONTAINER/EQUIPMENT TRANSFER (MOTOR) 205 8 
SHIPMENT PICK-UP OROER (MOTOR) 206 13 | 
SHIPMENT INFORMATION FOR EXPORT OECLARATION (MOTOR) 207 18 
SHIPMENT INFORMATION FOR IMPORT (MOTOR) 208 21 | 
FREIGHT OETAILS ANO INVOICE (MOTOR) 210 39 
FREIGHT OETAILS AND INVOICE SUMMARY (MOTOR) 211 7 
INQUIRY (MOTOR) 213 3 | 
SHIPMENT IOENTITIES ANO STATUS REPLY (MOTOR) 214 a 
REPETITIVE PATTERN MAINTENANCE (MOTOR) 346 22 | 
RESERVATION (BOOKING REQUEST - OCEAN) 300 19 | 
CONFIRMATION (OCEAN) 301 17 
CONTAINER/SPECIALIZEO EQUIPMENT PICK-UP OROER/CANCELLATION 302 10 | 
CANCELLATION (OCEAN) 303 5 
SHIPMENT INFORMATION (OCEAN) 304 39 { 
CONTAINER/EQUIPMENT TRANSFER (OCEAN) 305 9 | 
DOCK RECEIPT 306 28 | 
SHIPMENT INFORMATION FOR EXPORT OECLARATION (OCEAN) 307 22 
SHIPMENT INFORMATION FOR IMPORT (DCEAN) 308 28 | 
FREIGHT DETAILS ANO INVOICE (OCEAN) 310 30 { 
ARRIVAL NOTICE (OCEAN) 312 23 | 
INQUIRY (OCEAN) 313 4 | 
SHIPMENT IOENTITIES ANO STATUS REPLY (OCEAN) 314 6 
STATUS OETAILS REPLY (OCEAN) 315 7 | 
REPETITIVE PATTERN MAINTENANCE (OCEAN) 316 19 | 
SHIPMENT INFORMATION (RAIL) 404 5 1 | 
SHIPMENT INFORMATION FOR EXPORT OECLARATION (RAIL) 407 32 | 
SHIPMENT INFORMATION FOR IMPORT (RAIL) 408 35 | 
FREIGHT DETAILS ANO INVOICE (RAIL) 410 46 
FREIGHT OETAILS ANO INVOICE SUMMARY (RAIL) 411 7 
STATUS INQUIRY (RAIL) 413 3 
STATUS INFORMATION (RAIL) 412 19 | 
FLEET REFERENCE UPDATE 415 4 
REPETITIVE PATTERN MAINTENANCE (RAIL) 416 36 
WAYBILL INTERCHANGE (RAIL) 417 53 
AOVANCE INTERCHANGE CONSIST 418 4 
EMPTY CAR AOVANCE OISPOSITION 419 8 | 
CAR HANOLING INFORMATION 420 10 
COMMERCIAL INVOICING 800 13 | 
PAYMENT AUTHORIZATION 900 9 
COMPLETEO PAYMENTS 901 4 
PAYMENT ADVICE 902 8 
CONSOLIOATION MANIFEST 950 12 | 
STATUS INFORMATION FROM CONSOLIOATOR 95 | 4 
GENERALIZEO FEEDBACK 990 5 
AOVISORY INFORMATION 995 4 
FILE TRANSFER 996 3 
SET CANCELLATION 998 2 | 
ACCEPTANCE/REJECTION AOVICE 999 4 | 
BE S am Bee A een 
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Figure 4.13 List of Transaction Sets. 
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| 
| 
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| FLIGHT CONFIRMATION 


Set реет Require- Maximum Special Loop Loop 


CONTAINER/EQUIPMENT TRANSFER (AIR) 


T E wi Require- Maximum Special Loop Loop 


ment Use Process Control Index 
105 B8 M 1 O О О 
105 М9 М 1 Р17 о О 
105 N9 M 1 P18 О О 
105 D5 М 1 Р19 O O 
105 DG С 1 Р26 О О 
105 07 4 4 O O О 
105 $Е М 1 о О О 


AA AA A a 2 am RR Rios ca cy I ño ÉD X cn MEE E Pro dr: aca D ANN сағы... i аы жал. ады. OO, Oe абы 


| 
| 
| 
10 ment Use Process Control Index | 
101 B1 M 1 O О О | 
101 N9 O 20 О О О | 
101 R6 O 9 О О О | 
101 L9 O 40 O О О 
101 Y1 О 2 O O O | 
101 Q1 O 1 О О О { 
101 K 1 O 2 О О O 
101 SE M 1 O О О 
SHIPMENT INFORMATION (AIR) | 
Set S nt Require- Maximum Special Loop Loop | 
ID D ment Use Process Control Index | 
104 в2 M 1 О О О | 
104 N9 e 2 P36 O O | 
104 М7 С 1 О 1041 25 | 
104 м7 О 1 О 1041 О 
104 М1 С 1 О O О | 
104 м2 C 1 O О О | 
104 СЭ € 1 PG О О | 
104 c3 С 1 Р7 О О | 
104 Е 1 e 1 O O O 
104 Е2 C 1 P26 О © | 
104 F4 C 1 O O О | 
104 01 С 1 О О O | 
104 02 С i P26 О О | 
104 04 © 1 О О О 
104 U1 C | О о О | 
104 U2 С 1 P26 О О 
104 Ud C= 1 О О О | 
104 US E 1 О О О | 
104 06 С 1 P26 О О 
104 U9 C 1 О О О | 
104 ES С 1 ps 1042 10 
104 F6 С 1 P26 1042 О | 
104 E С 1 О 1042 О | 
104 05 С 1 PS 1043 10 
104 D6 C 1 P26 1043 O | 
104 07 e 1 О 1043 О 
104 R1 C 1 О О О | 
104 H1 С 3 Q O Q | 
104 H2 С 2 P11 О О 
104 H3 C 6 O O О { 
104 ES С 10 O 1044 25 { 
104 LO С 10 р2а 1044 О ) 
104 11 С 10 Р28 1044 О | 
104 L4 C 10 1044 О 
104 L7 O 10 P28 1044 O | 
104 X 1 С 1 1044 O | 
104 x2 С 1 P12 1044 О 
104 L3 C 1 O O O | 
104 K 1 O 2 О О О 
104 SE м 1 О О О | 
| 
| 
| 
E 


| 














| 


Figure 4.14 Data Segments in Each Transaction Set. 
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ac m output 


Inesoaurputssorserhesphysieal design are the rhys- 
ical schema and the definition of user views. The rhysical 
schema includes specific data structures (e.g.  iinkei list 
or inverted lists) and the recessary algorithms to mairtain 
and manage the data kase. The pnysical schema is in execu- 
table form. The definition of user views in the ЕГІ sense 
would be the interface software which would link a unique 
data tase at a specific command to the EDI standard in crder 


to translate the data for transmission. 


3. summary 


The design effort required to implement an ZDI 
interface within the WwWMCCS community is really at two 
levels. At the joint community level a logical design must 
Бе produced by the users and a physical schema by the appro- 
priate technical experts. At the command level software 
must Ге developed to interface command unique data Eases to 
the EDI standard in crder tc enable commands to successfully 


exchange data while still preserving their unique systers. 
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V. SUMMARY 

One cf the major problems in WWMCCS ADP today is the 
inability tc meet tke requirement for timely exchange of 
data among widely separated commands 1n a time sensitive 
environment while preserving security and accuracy. The 
current ıethod is to have commands use their unique applica- 
tiors for individual processing requirements and then use 
one of a few standard applications in order to interface 
with cther commands in a form which can be interpreted by 
then. This method entails many problems, not the least St 
which is a requirenent for manual intervention to translate 
data amcng various applications. Manual intervention 
increases the likelihood of problems with timeliness, accu- 
racy, and security. 

By implementing the EDI concept the members of the 
WWMCCS ccmmunity could substantially reduce these protlens 
Ly reducing the requirement for special interfaces (manual 
or automated) between each set of applications which need to 
exchange data. By tsing the EDI concept, any command which 
could translate to and from the EDi standard data set could 
exchange data with any other participating command. 

Figure 5.1 shows how data sets are exchanged amcng 
commands tocay. each dotted line represents an interface 
program designed to "translate" data between an application 
at one ccmmand and an application at another. Today 1Е МӘС 
Eu octurnish information directly to three applications at 
other commands (e.g. MTMC, JDA, MAC) special interface soft- 
ware must be written or all commands must be restricted to 
using the same software and hardware. Ша алаасіоп, іс апу 
other ccmmands needed to exchange data, they would need 


additional software to facilitate those interfaces (eg. MIMC 
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and JDA). Figure 5.2 Indicates һом data would be exchanged 
using the EDI concert. A sample data exchange usiny data 
will serve to further illustrate the function of the EDI 


standard data set. 


lm conne tm e ND" co» 
| 

| ЦСИ MSN I—OMTAC | 

| i | 

| a | 

| JDA | 

A ш. o 1 LL ] 

Figure 5.1 WWMCCS Interfaces Today. 

ш = — — | 

| 
| MSC (2250061285) 
| 


| MAC (£50612) . . . EDI (120685) . . . MTMC (120685) 


Figure 5.2 Data Exchange Using EDI. 


MSC is required to transmit inzormation which contains 
in it a data elezent which represents a_ date. a 
poupnsmet this information to JDA, MTHC, and MAC. Due to 
their qn gue applications, М5С E BC this date as 
hour-minutes-month-cCay-year (eg. 2250061285). 

The MSC-EDI interface translates this to the EDI stan- 
dard Lor date which is expressed (by community 
agreement) as day-mcnth-year (eg. 120685). 


The EDI software Paar ges the information for transmis- 
sicn and sends it tc the appropriate commands. 
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When the data is received at JDA, they translate, Sin 

command scitware, ie tuessformat required Dy unicu 

applications at JDA (eg. year-nonth-day 850612). he 

E 5 пара is received at MIMC it is used in th ED 
ormat. 
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HUSO (Dua 


е 


The most obvious advantage is that 1£ MTMC also interfaces 
with JDA nc additional interfaces would be required using 
the EDI concept. 

The EDI system pricvides for the transmission of the data 
Eua standard format. Each command provides the reans of 
LruusUating their data to to and from the standard with 
command unique software. This does, however, reduce tne 
number cf required interfaces and permits reduction of 
duplication in establishing a distributed data Dase 
approach. Each command will only require one interface, 
regardless of the tctal number of commands participating. 
Under the current system, if each command is to exchange 
data with every cther participating command the total nunter 
of interfaces required for each command would be N-1 (where 
N represents the numker of commands participating). The EDI 
standard tables could contain codes indicating which command 
is responsible for certain kinds of transaction sets or data 
segnents ard to whom these are distributed. Ta addition, 
when infcrmation is requested through the EDI interface, the 
central directory would have the means to locate the appro- 
priate ccmmand from which to draw the information. This 
would reduce the require ment for each command to maintain 
individual data directories for all the commands with which 
they interface. The use of a common interface permits many 
widely separated data bases to function virtually as a 
distributed data base. This wili help meet the identified 
requirement for a distributed data base approach to support 
JOPES. It is not a distributed data base in the rcutine 
sense Lut rather an interface which permits the exchange of 


data among separate cata bases. 
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The ESI Concept does work. It- is beirg used in the 
transportation industry today. Figure 5% ап М Figure 5.4 
are provided as a further illustration of its application 
(Ref. 21]. In figure 5.3 the sender types information into 
a terminal in the format required by the individual organi- 
zation (in this case using a forms mode and "filling in the 
BPlanks"). Figure 5.4 shows how the same data appears when 
it has teen converted into EDI standard data elements and 
data segments by means of the table driven EDI systen. 

Wise Of the EDI concept in WHMCCS would require nigh 
level support and commitment throughout the joint ccumunity. 
uM nitjal effort tc develop standard data sets and prepare 
command interfaces is indeed significant. However, since it 
will provide the capakility to exchange data among commands 
using various hardware, software, and data base management 
systems, it has the obvious advantage of providing much 
needed flexibiltiy. Commands would be able to utilize state 
of the art ADP technclogy tc solve their unique command and 
control ADP requirements without sacrificing the capability 
to exchange data effectively with otner commands. BY 
providing for data transfer without requiring standarization 
and duplication cf applications and data bases, EDI supports 
more efficient use cf ADP resources. Те EDI -Concept can 
help sove the data exchange problems in WWMCCS ADP tcday and 
contribute toward fullfilment of evolving requirements for 


exchanging data among commands. 


60 








i £ 


ү! 


ABC Company, 


есітсе COMO=0V 

(JES = 76/604 2a) 
"Ltr: асосида sui. 
‚сеч 2010г. ave. 
Fr-eceincoatitein. [sr 797732 


{ 


u Ci 1 
(Sample) 
ime. . 


Anytown, 


(22 Каере” 122255725990! 


California 


ЛИЕ 
YA e 
nn 


. co 


-- „m ma mo о әр 
ее. 
пече 


y ий ОШо a AO ee TS A se шщ ыл a al С 2 бы эль d 


A A A алы --е/ла Zeigen ARE Жалалы ÜBER орел алада en EDS nau 


Orxcwt. Ustcclhlusgzse 

Z2 Шесе CEN 5%. 

- сП) т æ гу = ш= = 

A a [stt = ету 
Месса CAPS. 

| іс Det 1982 

"ann. 
СЕ Ч -* 

27 ONES 
| ІШІ ІР УР UNE! 2252127505 О АА 
| NUMSER Fel. $ 2:22 2222 бк, 
| BUSES (4.5.1942 c6. 0€ C. ЕЕ tbs. prise Cels в. О 
| A Wu X; c eee st. a Ue ABC Trozi Fruiz £al ed NC 0.00 
| ШАН 5 "8:22 12757-520 2475-27 “8C Cut Green Beans 3.76 292.50 
| {з $423.30 
| 21. 1334110: 
| CONTACT: 


Figure 5.3 





61 





Transmission as Submitted. 





| 
| 


cmm c——dM— шы ee A o A аны AAA e A A A A ren A A i SO ————————À — — —L——————————— Á— —À— € —— 


TRANSACTION SET EXAMPLE - INVOICE # 44887221 


(BG SEGMENT) 
(GS SEGMENT) 


ST*880«-------- 
G01*821016*44887221«*820928«903417 
15“0100 | 
N1*87==9:98765432 10002 

N1*ST*SALES COMPANY»9»98765432 10070 
N2*GROCERY WAREHOUSE 3 70 

N3*22 WEST LONG ST 
N4*RICHLAND+"CA*394800 
N1«8Y«9«987654321000! 

N1«SU*ABC COMPANY, INC *9«123456789000 
LE«0100 

LS*0200 

G17*1 1*C4"131700#0037 13912345 
G69*ABC TRPCL FRUIT SALAD 
G20*24*1600*0Z 

LS*0210 

G72*1*02*«- 131700 1000*CA 

(Е“0210 
G17*30*CA«97600*003713967890 
G69*ABC CUT GREEN BEANS 
G20*24*800*0Z 

LE«0200 

G23*0 1*3*2000** 10«« 30 

G25*PB«03 

G3 1*4 1*CA 

G33*42450*4 1601 


(GE SEGMENT) 
(EG SEGMENT) 


| 
| 
| 
| 


Figure 5.4 
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Transmission in EDI Format. 
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